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Net/One,  the  local  area  network  produced  by  Ungermann-Bass,  has  been 
Installed  and  operated  in  the  Georgia  Tech  Fully  Distributed  Processing 
System’s  (FDPS)  testbed.  Currently  Net/One  interfaces  with  Prime  400 , 
Prime  550,  and  PDP  11/45  computers  which  are  looated  in  the  oomputer  lab 
and  several  different  types  and  brands  of  ASCII,  asynchronous  terminals. 
This  report  includes  a  description  of  the  design  and  operation  of  the 
various  Net/One  components,  a  disouaalon  of  the  rationale  for  the  selection 
of  Net/One  for  installation  in  the  FDPS  testbed,  our  initial  experiences 
with  Net/One  including  problems  encountered  and  their  solutions,  and 
concludes  with  a  description  of  the  plans  for  future  enhancements  to  its 
operation. 
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1.1  Ohlaatiwa  for  Tn.t^Tlln.  .  Network 

The  primary  objective  for  installing  a  looal  area  oomputer  network  was 
to  provide  a  versatile  research  vehlole  to  investigate  the  oonoepts  and 
utilisation  of  looal  networking  in  a  distributed  prooesaing  environment. 
This  researoh  is  part  of  the  Georgia  Teoh  Researoh  Program  in  Fully 
Distributed  Processing  Systems  (FDPS)  whioh  also  inoludes  researoh  on 
distributed  operating  systems,  distributed  data  bases,  programming 
languages,  theoretioal  and  formal  studies,  seourlty,  fault  tolerenoe, 
system  utilization,  physloal  interconnection  and  other  topics. 

A  secondary  objective  was  to  provide  relief  to  the  'growing  pains' 
being  experienced  in  the  school's  computer  lab.  Over  a  period  of  four 
years,  the  oomputer  laboratory  of  the  Sohool  of  Information  and  Computer 
Science  had  grown  from  a  very  small  computing  faoillty  consisting  of  two 
minicomputers  and  six  terminals  to  its  present  size  of  tan  minicomputers 
(some  of  whioh  are  quite  large)  accessible  by  more  than  60  tend  "ala.  With 
each  purchase  of  additional  equipment,  it  had  been  neoessary  to  provide  a 
physical  cable  between  eaoh  terminal  and  each  oomputer  that  the  terminal 
had  to  acoess.  For  terminals  attached  to  multiple  computers,  a  awitoh  at 
the  terminal  selected  the  desired  oable  (and  consequently  the  desired  com¬ 
puter)  .  Not  only  did  this  require  a  large  number  of  individual  cables  but 
some  of  the  oables  had  to  be  extremely  long  to  aooomodate  terminals  looated 
over  500  feet  from  the  computer  lab.  The  oost  of  material  and  labor  to 
provide  and  install  these  oables  bepan  to  eaoalate  and  the  resulting  web  of 
oables  led  to  frequent  failures  whioh  would  sometimes  take  days  to  isolate 
and  correct.  This  method  of  oonneoting  terminals  to  computers  also  resul¬ 
ted  in  each  terminal  requiring  multiple,  dedicated,  oomputer  I/O  ports, 
l.e.  a  dedicated  port  on  eaoh  oomputer  to  whioh  it  had  a  oable.  Since 
eaoh  terminal  oould  be  oonneoted  to  only  one  oomputer  at  any  given  time  and 
since  many  of  the  terminals  were  looated  in  one-man  offloes  and  used 
infrequently,  many  of  the  oomputer  ports  remained  idle  most  of  the  day. 

A  suitable  looal  network  promised  solutions  for  eaoh  of  these 
problems.  The  myriad  of  individual  oables  oould  be  replaoed  by  one  coaxial 
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oable.  With  the  looal  network,  all  ooaputer  ports  vers  Made  available  to 
all  terminals;  consequently,  eaoh  ooaputer  needed  to  support  only  as  aany 
ports  as  the  number  of  oonourrent  users  expeoted  or  allowed.  (Typically  it 
has  been  observed  that  the  number  of  simultaneously  active  users  on  eaoh 
system  is  approximately  40?  of  the  number  of  terminals  that  originally  had 
a  wired  port  to  that  system.)  Multiple  interconnecting  cables,  dedicated 
oomputer  ports,  and  seleotor  switohes  at  the  terminals  would  no  longer  be 
required. 

1 .2  BitlQPllfl  JCfi£  &£/£&&  Sslaatinn 

Net/One  was  selected  as  the  looal  network  researoh  vehicle  for  three 
primary  reasons.  First.  Net/One  was  one  of  the  few  looal  networks  that  was 
available  for  immediate  shipaMnt.  Many  of  the  other  produota  considered 
were  either  still  in  the  design  phase  or  just  beginning  the  prototype  phase 
of  development.  Several  of  the  looal  area  network  "produota"  were  only 
proposals  olting  a  "standard*  mode  of  operation  but  not  yet  in  the  design 
phase.  Second.  Net/One  provided  the  greatest  configuration  flexibility  of 
the  available  products.  The  configuration  and  operation  of  Net/One  is 
almost  completely  controlled  through  software  and  can  be  modified  on  a  port 
by  port  basis.  Third.  Ungermann-Bass  was  interested  in  establishing  a 
working  relationship  with  Georgia  Teoh  promising  full  produot  support  as 
well  as  teohnloal  advice  for  the  Georgia  Teoh  developed  enhancements  to 
their  produot  line. 
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let/Oae  Description 


2.1  Ovarvleu 

Met/One  is  a  general  purpose,  looal  area  ooanunioations  network  that 
supports  point-to-point  communications  between  digital  devices  suoh  as  oom- 
puter  systems  and  terminals.  Net/One  oonslsts  of  three  logical  components ; 
network  interface  units  (NIU)  which  serve  as  interfaces  between  user 
devioes  and  Net/One,  a  Network  Administrative  Station  (NAS)  whioh  supports 
configuration  and  monitoring  of  the  network,  and  a  Network  Development 
System  (NDS)  whioh  supports  oustom  program  development  an<*  testing.  A 
majority  of  the  functions  of  NAS  and  NDS  are  implemented  in  a  "special"  NIU 
and  a  ZILOG  1/20  microcomputer  with  64K  bytes  RAM.  (Some  debugging  aids  of 
the  NDS  are  aotually  looated  on  the  regular  NIUs).  These  components  are 
oonneoted  by  a  standard  coaxial  cable  supporting  baseboard  transmission 
with  a  bandwith  of  4  megabits/ second.  NIUs  are  oonneoted  to  the  ooaxial 
cable  by  an  aotive  devioe  known  as  the  tap  whioh  is  composed  of  drivers 
that  transfer  information  between  the  oable  and  the  NIU. 

Network  Network 

Administrator  Development 

Digital  Devioes 

\  I  / 


I  Network  I 
I  Interface  I 
I  Unit  I 


I - il&ftl 

coaxial  oable 

Figure  1.  Diagram  of  a  Net/One  Looal  Network 


Station  System 


|  Network  I 


I  Interface  I  <— >  I  ZILOG  I 
I  Unit  I  | _ | 


_ I _ 

_l_ 

—  IX&nl - 1 


2.2  JiifcttEk  Interface  JtajJiA  (MW 

One  NIU  oan  support  up  to  16  asynchronous  devioes,  or  eight  8-bit  or  4 
16-bit  parallel  devioes  that  may  differ  in  type,  transmission  rate,  parity, 
flow  oontrol,  disconnect  sequence,  eto.  As  shown  in  Figure  2,  the  major 
components  of  an  NIU  are  the  transceiver  interface,  the  network  processor 
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board  and  the  application  prooaaaor  boards.  They  oommunloate  via  an 
8Mbyte/aeoond  internal  data  buc.  The  transceiver  interface  performs 
address  recognition,  paoket  transmission  to  and  from  the  coaxial  oable, 
packet  framing  and  error  detection.  Eaoh  processor  board  can  support  4 
serial  and  either  two  8-bit  or  one  16-bit  parallel  devloes.  A  Z-80 
microcomputer,  64K  bytes  RAM  and  4K  bytes  of  PROM  looated  cn  each  board  are 
used  to  provide  a  software  interfaoe  to  eaoh  devioe.  In  addition  to  devioe 
interfacing,  the  network  processor  board  performs  many  funotiona  for  all 
NIU  components  suoh  as  controlling  traffio  inside  the  NIU,  establishing  and 
disconnecting  virtual  oirouits,  and  building  paoket  headers  for  outgoing 
paokets. 


1 

1 

0-3  II 

1 

applloa-  1  | 
tion  i_i 
processor  | 
boards  1 

Z-80  mi ora.  1 

£hv  Kvfas  DAM  ✓ 

1  1  1 

,-BrT  y  |  1 

OMXV  Oj  V*3S  AAn  V 

4K  bytes  PROM  | 
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i  i  i 

1  1  1 

II  II  II  II  II  II 

4  serial  2  8-bit 
ports  parallel  ports 

1  1  1 

1 Internal | 
iData  Bus) 

I ( 8Mby tes i 

Network  I 
Processor  I 
Bourd  | 
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Z-80  micro.  1 

filir  Kvf.i  B1U  / 

1  1  /seo) | 

O  “lv  Uj  LQ9  luin  N****^-^ 
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II  II  II  II  II  II 
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i  i  i 
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i  i  i 

i  i  i 
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\  |  | 

1 

1 

.1 

i  i  i 

1 

_l_ 

- Ijaal - 

ooxial  oable  (4Mbitc/seo) 

Figure  2.  Diagram  of  a  Network  Interfaoe  Unit  (NIU) 


2.3  ggtoprfc  Aflalalafcaitoc  autloo  (JUS) 

Network  management  is  the  responsibilty  of  the  NAS.  This  inoludes 
configuring  the  network,  monitoring  network  traffio,  logging  network  events 
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and  servicing  requests  from  Kins  for  down  loading.  As  mentioned  earlier, 
the  functions  of  the  NAS  are  implemented  on  a  speoial  NIU  and  a  ZILOG  1/20 
microcomputer. 

Bach  devioe  connected  to  an  NID  board  is  controlled  by  a  separate 
prooess  which  must  know  that  device’s  characteristics  in  order  to  oorreotly 
interface  with  it.  Figure  3  contains  an  example  of  the  configuration 
parameter  list  that  associates  devioe  characteristics  with  individual  NIU 
ports;  inoluded  in  Figure  3  are  the  characteristics  of  two  devioes  on  our 
network,  an  ordinary  CRT  and  a  PRIME  oomputer  port. 

When  an  NIU  is  initially  powered  up  it  automatically  requests  down¬ 
loading  from  the  NAS.  While  the  network  is  in  operation,  an  NIU  can  be 
downloaded  by  pressing  the  "reset"  switohes  located  on  the  front  panel  of 
the  NIU.  When  the  NAS  reoeives  the  request,  it  asks  the  ZILOG  microcom¬ 
puter  to  retrieve  kernel  code,  programs  and  devioe  characteristics  to  load 
in  the  NIU. 

The  NAS  has  a  few  other  features.  The  NAS  console  is  used  as  a  log¬ 
ging  devioe  where  NIU  downloading  aotions  and  errors  in  the  network  are 
recorded.  The  Net/One  systems  administrator  oan  connect  to  the  NAS  and  use 
special  admin8trator  commands  to  examine  devices,  create  virtual  oirouits 
between  two  remote  devices,  eto. 

2.4  Network  Development  System  (BPS) 

The  NDS  can  be  used  by  the  Net/One  user  to  write  his  own  programs  for 
controlling  the  activities  of  the  network.  Development  tools  inolude  those 
supported  by  the  ZILOG  1/20  miorooomputer  system,  i.e.  editor,  debugger, 
assembler,  file  utilities  eto.  plus  a  library  of  programs  supplied  by 
Ungermann-Bass  to  support  customer  programming.  There  is  an  interactive 
NIU  debugger  program  and  eaoh  NIU  has  a  test  toggle  switoh  that  causes  down 
loading  with  user  specified  test  programs  and  data  instead  of  the  data 
normally  down  loaded  by  the  NAS.  In  addition,  eaoh  processor  board 
(network  and  application)  is  furnished  with  a  memory  debugger  and  a  speoial 
set  of  sockets  for  debugger  PROMs. 
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Configuration  ProftTMi 


Is  this  devioe  serial  asyno, 
serial  syno  or  parallel 
Does  it  use  standard  or 

extended  RS-232  signalling 
Row  many  NULs  after  eaoh 
linefeed 

How  many  NULs  after  eaoh 
oarriage  return 
When  echoing  enabled,  add 

linefeed  after  each  carraige 
return 

How  many  stop  bits 
How  many  data  bits  per  oharacter 
Odd  parity,  Even  parity,  or 
No  parity 

Does  this  device  support  flow 
control 

Does  it  use  characters  or 
RS-232  line  signals 
CTS : RTS  or  DSR:DTR 
Is  this  a  command  device 
Is  it  also  a  data  devioe 
Command  mode  initiation  oharacter 
Backspace  oharacter 
Line  delete  character 
Completion  character 
Should  NIU  commands  be  echoed 
Should  NIU  command  responses  be 
suppressed 

Does  this  device  support  lower 
case 

Disconnect  sequence 
Should  circuit  data  be  eohoed 
locally 

Input  buffer  size  (2-254) 

Output  buffer  size  (2-254) 

Input  buffer  flow  control 
threshold 
Baud  rate 

Should  a  circuit  be  initiated 
from  this  devioe  at  startup 
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Figure  3*  The  Configuration  Program 
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2.5  Mt/fino.  .Qatritlan 

Net/One  supports  the  CSMA/CD  (Carrier  sense  multiple  aooess/oolllsion 
detection)  access  protocols  Both  virtual  oirouits  and  datagrams  are 
allowed.  Paokets  are  broadcast  over  the  ooaxial  cable  and  "picked  up"  by 
those  NIU's  to  which  they  are  addressed.  Figure  4  gives  the  format  for  a 
Net/One  packet.  The  local  destination  header  contains  the  destination  of 
the  packet  within  the  local  network.  If  the  paokot  is  being  sent  to 
another  local  network  then  the  local  destination  is  the  "gateway"  NIU  to 
that  other  network.  The  internet  destination  header  then  defines  the  final 
destination  NIU  of  the  packet  in  the  other  network. 


1  |<— Destination  NIU  Address—  >| 

III  1 

1  1  1 

ICI  | 

iFlgslLooal  header)  Internet  header  I 
III  1 

Data 

I R | Figs  1 
|C|  | 
1  1  1 

2-3  12  18  0-22  2  2-3 
(numbers  below  paoket  represent  field  length  in  bytes) 
Figure  4.  A  Net/One  Paoket 


2.5.1  Balias  Aft  iteTlM  CiMninl nation 

Bach  NIU  has  a  network  address,  i.e.  27.  The  network  processor  board 
is  always  known  as  the  "a"  board  and  its  ports  have  addresses  suoh  as  27a1 , 
27a2  ...  27a6.  Application  boards  are  known  as  "b",  "o"  and  "d"  boards 

and  their  ports  follow  the  same  addressing  soheme,  i.e.  27b1,  27o4,  27d6 

etc. 

A  device  can  communicate  with  another  devioe  by  requesting  a  virtual 
circuit  to  an  address;  this  is  done  utilizing  the  oonneot  command,  i.e., 

oonneot  27 o2 

If  the  device  connected  to  27o2  is  free  (a  devioe  may  participate  In  only 
one  virtual  circuit  at  a  time)  a  virtual  oirouit  is  established.  Any  data 
transmitted  by  a  devioe  at  one  end  of  a  virtual  oirouit  is  delivered  to  the 
other  end  in  the  same  order  as  transmitted.  Either  devioe  may 
disconneot/disestablish  the  virtual  oirouit  at  any  time. 
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All  devices  have  a  devioe  "type"  which  can  be  either  command,  data  or 
both  command  and  data.  Command  devices  can  request  virtual  circuit  connec¬ 
tions,  data  devioes  cannot  request  but  may  aooept  virtual  circuit  connec¬ 
tion  requests  and  a  command/data  devioe  may  do  either. 

2.5-2  Sending  jud.  BsolsYing  Packets 

NIUs  control  packet  traffic  in  the  network.  When  a  device  or  com¬ 
ponent  of  an  NIU  supplies  the  data  for  a  packet  the  network  processor  board 
builds  a  packet  header  for  that  data  and  sends  the  packet  to  the  transmit¬ 
ter.  The  transmitter  frames  the  packet,  adds  a  CPC,  and  plaoes  it  in  a 
FIFO  queue  for  transmission.  When  the  packet  arrives  at  the  head  of  the 
queue,  the  receiver  notifies  the  transmitter  to  place  the  packet  on  the 
coaxial  cable  at  a  time  when  it  detects  no  other  traffio  on  the  cable.  If 
the  recel'  it  detects  data  on  the  network  while  the  paoket  is  being  trans¬ 
ferred,  i,  jit  uls  a  "collision4  to  the  transmitter.  The  transmitter 
broadcasts  a  collision  message  to  all  other  NIUs;  those  NIUs  that  were 
transmitting  will  attempt  a  retransmission  after  a  random  time  delay.  The 
local  transmitter  will  also  retransmit  the  paoket  after  a  random  time 
delay.  Transmitted  packets  are  kept  in  a  oiroular  queue  where  they  can  be 
retrieved  for  retransmission  if  neoessary. 

When  a  paoket  addressed  to  a  receiver's  NIU  is  detected  on  the  or  .x, 
it  is  queued  in  a  FIFO  buffer.  A  CRC  oheok  is  made;  if  an  invalid  paoket 
is  found,  it  is  removed  from  the  queue  and  a  message  is  broadoasted 
requesting  retransmission  of  the  packet.  (All  packets  have  a  unique  paoket 
id) .  If  the  paoket  is  valid  an  interrupt  is  generated  to  the  processor 
board  whloh  will  look  at  the  paoket  header  and,  depending  on  the  devioe  to 
which  the  packet  is  addressed,  will  either  reoeive  the  data  or  notify  one 
of  the  applications  boards  to  reoeive  the  data. 

2.6  Other  Rnhanwentw  l Tellable  for  Met/One 

Up  to  this  point  we  have  described  the  looal  network  that  we  have 
installed  in  the  Information  and  Computer  Science  Lab  at  Georgia  Teoh. 
Since  that  Installation,  Ungermann-Bass  has  produoed  a  lOMbit/seoond  local 
network  (to  which  we  oould  upgrade)  and  optional  Ethernet  compatible 
software  for  the  10Mbit/ second  network. 
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Our  ZXLOG  microcomputer  system  currently  uses  floppy  disks.  A 
Winchester  disk  drive  is  now  available  whioh,  along  with  an  IEEE.  448  bus 
structure  between  the  miorooomputer  and  the  special  NIDf  reduces  the  down¬ 
loading  time  of  an  HID  processor  board  from  approximately  90  aeoonda  to  19 
seoonds. 
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CHAPTER  3 

Our  Experiences  With  let/One 

3.1  Hartiart  munition  iafl.  TtaUag 

Net/One  was  installed  In  the  ICS  oomputer  lab  in  September,  1980.  The 
original  configuration  included  9  Network  Interface  Units  (NIU's),  1 
Network  Administration  System  (NDS)  and  1  Network  Development  System.  This 
equipment  allowed  for  108  general  purpose  asynchronous  ports,  (We  do  not 
use  the  parallel  ports.) 

3.1.1  glow  Cflfttrai 

Net/One  supports  three  methods  of  flow  control:  using  ASCII  oontrol 
characters,  using  RS-232  Request-To-Send  and  Clear-To-Send  (RTS/CTS) 
control  lines,  or  using  the  Data-Set-Ready  and  Data-Terminal- Ready 
(DSR/DTR)  hardware  control  lines.  None  of  these  methods  were  completely 
suitable  for  our  operation.  Character  flow  oontrol  was  not  a  viable  option 
because  several  applications  on  the  PRIME  oonputer  system  already  used  all 
of  the  ASCII  control  characters;  e.g.  the  full-soreen  editor.  (Any  of  the 
standard  ASCII  control  codes  except  null  can  be  used;  typioally  DC3  (ctrl- 
S)  is  used  to  stop  output  and  DC1  (oontrol  Q)  is  used  to  rostart  output.) 
The  asynchronous  communications  hardware  on  the  PRIME  computers  did  not 
support  RTS/CTS  hardware  lines  nor  did  they  support  a  DSR  oontrol  line. 

A  solution  was  eventually  found  involving  the  use  of  the  PRIME'S 
carrier  detect  line  (normally  used  for  modem  oontrol)  as  a  DSR  control 
line.  The  Primos  operating  system  was  modified  to  use  the  carrier  detect 
line  as  a  flow  control  sense  and  the  PRIME'S  oarrier  detect  and  DTR  lines 
were  wired  to  the  networks  DTR  and  DSR  respectively.  While  implementing 
this  solution,  an  error  in  the  Primos  operating  system  oausing  lnoorreot 
manipulation  of  the  DTR  oontrol  line  was  a.  covered  and  fixed.) 

We  encountered  yet  another  flow  oontrol  problem  caused  by  devices  at 
one  end  of  a  virtual  circuit  receiving  data  at  muoh  slower  speeds  than 
being  transferred  by  host  computers  at  the  other  end.  Net/One  would  not 
send  an  x-off  signal  to  a  transmitting  devioe  until  the  reoeiving  buffer 
was  8  characters  away  from  being  full.  If  an  x-off  signal  was  sent  to  a 
PRIME  oomputer,  it  was  very  likely  that  more  than  8  oharaoters  would  be 
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sent  to  the  deviow  before  the  PRIME  would  suspend  transmission.  As  a 
result,  slower  devioes  like  hardoopy  terminals  were  losir  -  oharaoters. 
Ungermann-Basa  solved  this  problem  for  us  by  making  the  input  buffer  flow 
oontrol  threshold  user-programmable  in  the  next  software  release.  This 
feature  also  enabled  us  to  conneot  the  PDP-11/45  to  Net/ONE.  Our  11/45  did 
not  support  flow  oontrol;  however  by  setting  the  transmission  speed  to  4800 
baud  and  setting  the  input  buffer  threshold  to  a  high  value  we  were  able  to 
get  reliable  transmission. 

3*1.2  Parity 

Ue  were  required  to  change  our  terminal  parity  standard  from  mark 
parity  (always  on)  because  the  Net/One  software  restricted  transmitted 
ASCII  data  characters  to  have  the  parity  bit  odd,  even,  or  always  off 
(spaoe  parity).  No  provision  was  made  to  use  mark  parity  or  to  simply 
ignore  the  parity  bit  on  input.  Since  some  of  the  terminals  we  were 
currently  using  oould  not  generate  either  even  or  spaoe  parity,  odd  parity 
was  chosen  as  the  standard  for  our  terminals.  (Sinoe  oomputer  ports  were 
data  devices,  we  kept  them  configured  for  mark  parity.  If  Net/One 
encounters  a  parity  bit  set  to  an  unexpected  value,  it  simply  "ignores"  the 
byte  (l.e.  Net/One  passes  it  through  to  the  devioe  at  the  other  end  of  the 
oirouit  without  examining  the  contents  for  a  recognizable  command.) 

3*1*3  Cable  Connections  gad.  Tei*minetoi*e 

After  solving  flow  control  and  parity  problems  the  network  was  still 
unstable.  It  took  us  a  while  to  discover  that  the  oause  was  a  faulty 
terminator  that  was  reflecting  signals  baok  into  the  ooaxial  oable.  He 
also  discovered  that  oonneotlng  the  pieces  of  the  ooaxial  oable  is  not  easy 
or  foolproof.  If  one  connection  anywhere  along  the  ooaxial  oable  is 
faulty,  the  entire  looal  network  beoomea  unstable.  Best  results  were 
obtained  when  we  connected  the  oable  in  a  straight  line  (i.e.  no  "T"  con¬ 
nections)  . 
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3.2  floftiart  laaUimioa  j iM  toiUag 

3.2*1  Release  1.2 

The  original  Net/One  software,  release  1.2,  provided  the  following 
commands  to  Net/One  users: 

famanfl  Exnlanatlon 

conneot  device  <address>  virtual  circuit  request 

<LF>D  virtual  oirouit  disconnect 

list  disoonneot  list  disconnect  command 

list  address  list  my  network  address 

Figure  5.  Some  Net/One  User  Commands 

Commands  could  be  abbreviated  to  the  first  letter  of  eaoh  word,  i.e.  "o  d 
27a3"  for  "oonneot  devioe  27a3*. 

There  were  a  few  shortcomings  in  release  1.2.  Users  had  to  know  all 
of  the  speclfio  network  addresses  assigned  to  a  computer  system  that  they 
wanted  to  access.  Network  address  assignment  was  governed  more  by  physical 
proximity  of  the  N1U  whloh  did  not  neoessarily  follow  a  logioal  order.  If 
for  some  reason,  a  computer  port  address  had  to  be  moved,  all  users  needed 
to  be  notified  of  the  ohange.  If  the  first  connect  was  unsuccessful 
because  the  port  at  the  specified  address  was  already  participating  in 
another  virtual  circuit,  the  user  was  required  to  repeat  the  oonneot 
sequenoe  for  other  addresses  until  a  free  port  was  found. 

Other  problems  resulted  from  Net/One's  non-transparent  transmission  of 
some  oharaoters.  Specifically,  some  of  the  ASCII  oontrol  characters  were 
inoorrectly  interpreted  and/or  were  not  passed  through  the  virtual  cirouit. 
This  problem  was  first  observed  with  programs  that  controlled  the  cursor 
positioning  on  some  brands  of  CRT  terminals.  It  was  later  discovered  that 
the  break  key,  used  by  the  Prime  computers  as  a  software  interrupt  signal, 
was  transmitted  through  the  virtual  oirouit  as  an  ASCII  NULL  which  the 
PRIME  computer  ignored. 

3.2.2  Release  2..1 

In  March,  1981,  release  2.1  arrived.  There  were  a  few  new  features 
a.?d  several  Improvements  over  the  original  software  release.  The  most  wel- 


Georgla  Institute  of  Technology 


Net/ One  Looal  Network 


Chapter  3 


Our  Experiences  With  Net/One 


Pace  13 


cose  of  the  new  features  was  the  global  network  name  server.  This  feature 
allowed  a  looal  network  user  to  request  a  virtual  circuit  by  specifying  a 
symbolic  naae.  The  name  server  then  broadoasted  the  request  to  all  network 
ports.  Any  of  the  network  porta  that  had  been  configured  to  respond  to 
that  naae  and  that  were  not  currently  part  of  a  virtual  oiroult  would  ack¬ 
nowledge  the  request.  Whan  the  oiroult  was  established,  the  user  received 
confirmation  showing  the  phyaioal  network  address  that  aooepted  the  oonneo- 
tion  request.  If  all  network  porta  configured  with  that  ayabollo  naae  were 
ourrently  tied  up  in  another  virtual  oiroult,  the  user  reoelved  the  aessage 
'All  ports  are  busy'.  If  no  network  ports  were  oonflgured  with  that  naae 
or  if  none  of  the  oonflgured  ports  were  operational,  the  user  reoelved  the 
message  'No  resouroe  answers  by  that  naae'. 

Other  major  enhancements  were  aade  to  the  configuration  program.  The 
program  was  auoh  easier  to  use  and  added  such  features  as  extended  RS-232 
line  signals  for  serial  and  parallel  ports  and  user  programmable  input 
buffer  flow  oontrol  thresholds. 

3.3  ia-Bam  ttedlfloctiang  J&  Itfc/Ant.  aaffrt 

With  a  small  modification  to  the  PRIMOS  operating  system  and  oorreo- 
tlons  to  the  Net/One  software  from  Ongemann-Bass,  we  implemented  a  method 
of  foroing  a  virtual  oiroult  disconnection  when  a  Prime  ooaputer  user  log¬ 
ged  off.  The  looal  network  aade  logging  on  and  off  a  two  step  prooess: 
requesting/disoonneoting  a  virtual  oiroult  and  logging-on/logging-off  a 
computer  system.  Many  users  were  logging  off  but  not  dlsoonneotlng  the 
virtual  oiroult  thus  not  freeing  that  ooaputer  port  for  another  user.  This 
modification  oauaed  automatic  virtual  oiroult  dlsoonneotion  when  the  user 
logged  off.  In  order  to  implement  this  faoillty,  it  wen  neoessary  to 
reconfigure  all  our  network  oomputer  ports  and  oomputers  to  use  odd  parity. 
(Since  we  wanted  Net/One  to  reoognize  the  disoonnect  sequenoe  issued  by  the 
ooaputer,  eaoh  ohar^oter  of  the  disconnect  sequenoe  had  to  have  the  parity 
bit  set  to  something  that  Net/One  understood.) 

Another  oorreotlon  to  the  Net/One  software  removed  the  sensitivity  to 
ASCII  oontrol  codes.  This  oorreotion  allowed  the  use  of  oursor- positioning 
programs  with  no  restrictions. 
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3.4  Current  ntrfflimanQt 

Curre  ely,  we  have  10  NIUs  with  124  available  porta  of  which  only  11 
are  not  yet  eonneoted  to  any  devioe.  44  oomputer  porta  provide  aooesa  to 
five  PRIME  computers  running  Priaoa  and  a  PDP  11/45  ooaputer  running  Unix 
version  7.  Most  devioes  run  -vt  96OO  baud. 

We  have  not  as  yet  made  any  in-depth  performance  analyses  of  Net/One. 
However,  we  have  bad  Net/One  for  almost  a  year  and  onoe  Installed  we  nevor 
witnessed  any  component  failures  nor  were  we  ever  required  to  bring  the 
network  down  beoause  of  hardware  or  software  problems  (and  we  purchaser  one 
of  the  first  Net/One  networks  manufactured).  Our  oomputer  systems  perform 
character  eoholng  for  all  terminals,  and  even  with  heavy  terminal  aotlvlty 
we  have  never  noticed  any  delays  induoed  by  Nat/One.  Finally,  both  our 
novioe  and  very  experienced  users  have  found  that  Net/One  is  easy  to  use. 

3.5  Unsolved  fpnhl«M 

There  remain  a  few  problems  with  Net/One  that  both  Goorgia  Teoh  and 
Ungermann-Bass  are  attempting  to  solve.  Some  of  these  problems  are  addres¬ 
sed  in  Revision  3.0,  soon  to  arrive.  Net/One  still  transmits  break  charac¬ 
ters  as  ASCII  NULLS.  Users  oannot  send  one  character  that  mstohos  the 
first  character  of  the  disconnect  sequenoe  beoause  vhat  character  is  not 
transmits ;d  uatil  another  character  not  in  the  dlsoonneot  sequenoe  is 
typed.  Also,  the  local  network  remains  sensitive  to  the  ASCII  parity  bit. 

Occasionally,  a  virtual  circuit  is  broken  by  the  network.  This  leaves 
ihe  computer  user  logged  in  to  the  oomputer.  Sinoo  the  olrouit  to  that 
computer  no  longer  exists,  any  other  terminal  user  may  connect  to  that  oom¬ 
puter  port  and  find  himself  in  the  middle  of  the  terminal  session  of  the 
user  'those  circuit  was  broken.  (We  have  just  recently  reoelved  a  patoh  for 
Revision  2  1  softest «»  that  appears  to  take  care  of  this  problem).  Also, 
occasionally,  a  number  of  Net/One  ports  beoomes  unavailable  to  the  rest  of 
the  looal  network  for  no  reason.  Typioally,  this  problem  ooours  with 
groups  of  4  network  ports  up  to  and  Including  ,*n  entire  NIU  (16  ports).  In 
order  to  make  these  ports  usable  again,  it  is  neoessary  to  reload  the  NIU. 

Reloading  an  NIU  la  very  easy.  It  requires  pressing  reset  switohes  on 
the  front  panel  of  the  NIU  and  then  waiting  approximately  90  seconds  per 
board.  However,  there  is  no  provision  for  reloading  only  one  board.  If  we 
need  to  reconfigure  a  port  or  if  a  board  hangs,  we  must  ask  all  users  000- 
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neoted  to  other  porta  on  the  NIU  to  log  oft  wifcil  the  NIC  la  reloaded. 
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Futv'e  Plana  for  Rat/ One 


4.1  atamAfar 

Working  closely  with  Ungera.ann-Bess,  wa  plan  to  deve  \  saourlty 
systan  within  tha  looal  network.  First,  wa  expoot  to  implement  a  password 
saourlty  systan  requiring  a  password  to  ha  supplied  and  oheoked  before  a 
new  virtual  oirouit  oan  be  established.  This  will  b«i  used  to  control 
aooess  to  those  systeas  that  require  additional  saourlty  suoh  as  those  used 
for  researoh.  Our  general  aooess  oonputers  will  not  require  a  password  for 
conneotion. 

We  also  plan  to  implement  an  aooess  list  saourlty  systan  within  the 
looal  network.  The  aooess  list  saourlty  will  allow  oonneotions  to  speoiflo 
oonputers  fron  a  list  of  teminal  locations.  This  will  serve  to  further 
deter  non-authorised  usage  of  sensitive  resouroes. 

Related  to  the  seourity  systan  will  be  the  lnplenentatlon  of  a  one- 
step  login  process.  This  would  Involve  a  oonaand  suoh  as 

■.ogin  <usernane>  <projaot> 


that  would  cause  the  looal  network  to  oreate  a  virtual  oirouit  to  the  oom- 
puter  systan  associated  with  the  usernnne  and  project  information  and  then 
exeoute  a  surrogate  login  for  the  user.  The  next  thing  that  the  user  would 
see  is  the  password  prompt. 

*.2  1.25. 

We  propose  to  use  a  portion  of  the  X.25  interfao*  between  the  host  and 
the  NIU  to  aot  as  an  X.25  DC 55  to  support  multiple  virtual  clrouits  on  one 
physical  conneotion.  Also,  an  lnplenentatlon  of  the  X.25  DTE  protoool  in 
an  NIU  is  desired  to  allow  dlreot  oonneotion  between  Net/Oue  and  an  X.25 
Publio  Packet  Switched  Network,  e.g.  Telenet. 
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4*3  Studies 

We  plan  to  oarry  out  soae  performance  studies  on  the  looal  network. 
Particularly,  we  would  like  to  find  out  how  nuoh  traffic  it  taken  to  induoe 
a  noM  cable  degradation  of  Net/One  perforaanoe. 

4.4  Additional  ainiot 

We  are  planning  to  expand  the  ourrent  looal  network  hardware  to  sup¬ 
port  more  terminal  uaera  and  ooaputer  ayateaa.  Figure  6  contains  th» 
diagram  of  our  future  looal  network.  The  first  atep  of  the  expansion  has 
been  to  order  20  additional  Net/One  porta  raising  our  ourrent  network  port 
count  to  144.  (When  fully  expanded,  the  Net/One  looal  network  oan  support 
255  NIU's  for  a  total  of  4080  general  purpose  asynchronous  porta).  We  will 
eventually  support  the  following  ooaputera: 

[1]  IBM  Seriec/1  running  under  the  EDX  operating  system.  We  ourrently 
have  three  of  these  maohinea  in  our  ooaputer  lab  used  for  both  aoadeaio  and 
research  purposes. 

[2]  HP  1000  F  series  under  the  RTE  IV  B  operating  system.  This  system 
will  be  used  as  a  graphics  support  processor  driving  several  Hewlet  Packard 
graphlos  dev:'  oes  including  a  plotter  and  oolor  graphics  terminals.  This 
system  supports  mainly  an  aoadeaio  user  oosaunlty. 

[31  VAX  11/780  running  under  the  VAX  Unix  version  7  operating  system. 
This  system  will  also  be  used  to  link  Georgia  Teoh  to  CSNET,  the  national 
computer  solenoe  network. 

[4]  CDC  Cyber  74  running  under  the  NOS  version  1.4  operating  system. 
This  computer  along  with  a  CDC  6400  supplies  the  Georgia  Teoh  oaapus  with 
general  computing  resour oes. 

[5]  Several  single  user  microcomputer  workstations  capable  of  stand¬ 
alone  network  operation. 
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